Risikomanagement in agilen Projekten

Ein professionelles Risikomanagement erlaubt, frühzeitig auf Abweichungen zu reagieren und ermöglicht damit ein effizientes Projektmanagement. Gerade der Einsatz agiler Methoden, wie beispielsweise Scrum, bietet verschiedene Vorteile, die im vorliegenden Artikel dargestellt werden. Aus diesen ergibt sich, dass der Fokus des Projektleiters im Risikomanagement auf den externen Umfeldfaktoren liegen kann. Initiales Risikomanagement. Als Vorgehensmodell macht Scrum keine Aussagen dazu, wie ein Projekt aufgesetzt wird. Stattdessen konzentriert sich Scrum auf die Steuerungsphase des Projektmanagements nach DIN 69901. Entsprechend existieren in der Scrum-Community unterschiedliche Ansätze für das Risikomanagement im Projekt. Dabei wird häufig übersehen, dass bereits in der Planungsphase des Projektes eine initiale Risikoanalyse durchgeführt werden sollte. Dazu empfiehlt es sich, einen Risikoworkshop mit dem gesamten Team durchzuführen, um einen gemeinsamen Blick auf die Risiken und dadurch ein besseres, gemeinsames Projektverständnis zu bekommen. Dabei kommen die bekannten Prozesse und Methoden zum Einsatz:  Identifizieren Aufdecken und qualifizieren aller Risiken mittels Risikoworkshop, Input aus der Umfeldanalyse, Vergleich mit anderen Projekten, Kreativitätstechniken.  Analysieren Untersuchen der Risiken hinsichtlich deren Ursachen/Auslösern und quantifizieren der Eintrittswahrscheinlichkeit und der Schadenshöhe. Berechnen des Risikowertes und Erstellung des Risikoportfolios.  Planen Festlegen von korrektiven oder präventiven Maßnahmen für jedes Risiko.  Steuern Risiken regelmäßig auf Aktualität und die ergriffenen Maßnahmen auf Wirksamkeit prüfen. Reagieren bei Eintreten von Risiken. Die Umfeldanalyse gliedert das Umfeld des Projektes in interne und externe Faktoren oder in direkte und indirekte Faktoren in Abhängigkeit ihrer jeweiligen Nähe zu dem bzw. ihrer Wirkung auf das Projekt. Aus den jeweiligen Faktoren können sich Risiken für das Projekt ergeben. Typische Beispiele für interne Umfeldfaktoren sind das Projektteam, direkte Stakeholder (Auftraggeber, Lenkungskreis, Anwender, Betriebsrat), Projekträume oder Projekt-organisation. Beispiele für externe Umfeldfaktoren sind Gesetze und Normen, technische Restriktionen, gesellschaftliche und politische Faktoren, die wirtschaftliche Entwicklung oder der Wettbewerb. Den sich aus dem Projektumfeld, welches für jedes Projekt unterschiedlich ist, ergebenden Risiken muss auch in agilen Projekten begegnet werden. Daher ist es wichtig, sich bereits zum Projektstart über die Risikoexposition des Projektes Klarheit zu verschaffen. Laufendes Risikomanagement. Beim Einsatz agiler Vorgehensmodelle erlebt man häufig eine Konzentration des Teams auf die Steuerungsphase des Projektes. Dies führt dazu, dass man in der Praxis häufig auf Scrum-Projekte trifft, die kein dediziertes Risikomanagement betreiben. Sei es aus dem falschen Verständnis heraus, dass dies mit Scrum nicht notwendig sei, oder einfach, weil Scrum nicht als Vorgehensmodell sondern als Projektmanagementmethode verstanden wird. Oft sind es nicht die dem Management berichteten und transparenten Risiken, die den Projekterfolg gefährden, sondern zunächst verdeckte und sich gegenseitig verstärkende Risiken. Scrum, genauso wie andere agile Vorgehensmodelle auch, setzt auf grundlegenden Prinzipien und Methoden auf:  Agiles Manifest  Scrum Ereignisse  Transparenz  Impediment Backlog  User Stories  Schätzungen im Product Backlog  Verantwortung  Inspect and adapt  Potentially shippable increment Diese unterstützen dabei, genau diese verdeckten Risiken aufzudecken und geeignete Gegenmaßnahmen zu ergreifen. Agiles Manifest. Das agile Manifest fordert dazu auf, Veränderungen zu begrüßen und mit ihnen umzugehen, den Kunden aktiv einzubinden und wertvolle Software zu schaffen, welche möglichst früh geliefert werden kann. Erfolg wird durch die Zufriedenheit des Kunden definiert. Dazu fokussieren wir uns auf Einfachheit, die Kunst „the amount of work not done“ zu maximieren. Die tägliche Projektarbeit zeigt: Je weiter in die Zukunft geplant wird, desto größer ist die Wahrscheinlichkeit, dass ein Ereignis eintritt, mit dem in der Planungsphase nicht gerechnet wurde. In Scrum wird deshalb in der Planungsphase der nächste Sprint fokussiert. So kann das Projekt flexibler auf geänderte Bedingungen seines Umfelds reagieren. Risiken, die während eines Sprints erkannt werden, können schon bei der Planung des Folgesprints berücksichtigt werden. Das gemeinsame agile Wertesystem fordert alle Projektbeteiligten dazu auf, Herausforderungen und Hindernisse aktiv anzugehen, Risiken direkt aus dem Weg zu räumen und den Erfolg des Projektes nachhaltig zu sichern. Scrum Ereignisse. Scrum bietet dem Projektleiter, dem Product Owner und dem Team vier wesentliche Eingriffspunkte für das Risikomanagement: Das Sprint Planning, das Daily Scrum, das Sprint Review und die Sprint Retrospektive. Im Sprint Planning werden die beiden Fragen „Was wird im nächsten Sprint getan?“ und „Wie erreichen wir das Ziel?“ beantwortet. Im Rahmen der Planerstellung für den nächsten Sprint werden hier Ressourcenverfügbarkeiten berücksichtigt und ein gemeinsames Verständnis des zu erreichenden Ziels erarbeitet. Risiken werden durch das Team direkt im Forecast für den nächsten Sprint berücksichtigt. Durch diese Selbstorganisation im Team erhöht sich das Verantwortungsbewusstsein und damit auch die gelieferte Qualität. Das Daily Scrum bietet dem Team die Möglichkeit, den Fortschritt auf einer täglichen Basis abzuschätzen und zu beobachten, um frühzeitig steuernd einzugreifen. Das Team synchronisiert hier seine Tätigkeiten für die nächsten 24 Stunden und gibt eine Prognose ab, welche Arbeiten bis zum nächsten Daily Scrum erledigt sein werden. Risiken können so während der Entwicklung erkannt und entweder direkt im Team oder in Zusammenarbeit mit dem Product Owner und dem Scrum Master gelöst werden. Das Sprint Review gibt den Projektstakeholdern die Möglichkeit, die geleistete Arbeit zu sichten und hinsichtlich ihres Nutzens zu bewerten. Dies erlaubt es, frühzeitig festzustellen, ob das Projekt auf dem richtigen Kurs ist. Dabei gilt: Je größer die Begeisterung für das Produkt ist, desto größer wird auch die Motivation des Entwicklungsteams. Umgekehrt zeigt eine negative Kundenreaktion, dass das Projekt auf dem falschen Weg ist und versetzt den Projektleiter und den Product Owner in die Lage, korrigierend einzugreifen. Im Extremfall kann das Projekt frühzeitig abgebrochen werden, wenn erkannt wird, dass der Business Value nicht mehr erbracht werden kann. Insgesamt bringt das Review durch den Austausch von Entwicklern und Stakeholdern ein gesteigertes gegenseitiges Verständnis, indem alle Diskussionen auf dem erlebbaren Produkt aufsetzen. Dadurch wird es möglich, neue Erkenntnisse darüber zu gewinnen, wie das Produkt weiter verbessert werden kann. In der Sprint Retrospektive rekapituliert das Team den letzten Sprint und identifiziert Verbesserungspotentiale. Dazu werden die Umsetzung und Wirksamkeit der Maßnahmen aus dem letzten Meeting analysiert und neue Maßnahmen definiert. Ziel ist es, den Entwicklungsprozess und die Teamzusammenarbeit zu verbessern und effektiver zu gestalten. Im Rahmen dieses Meetings können aufgetretene Risiken des letzten Sprints analysiert und Lösungen für den zukünftigen Umgang mit diesen erarbeitet werden. Insgesamt zeichnen sich zwei Ansatzpunkte für das Risikomanagement durch die Scrum Ereignisse ab: Einerseits wird das Team stärker in die Verantwortung genommen und aktiv in das Risikomanagement eingebunden. Andererseits bieten sich durch die definierten Abläufe vielfältige Möglichkeiten sowohl zur Identifikation von Risiken als auch zur Definition von Maßnahmen und damit zur Risikosteuerung. Transparenz. Durch die kurzen Sprintzyklen und die Sprint Reviews wird der aktuelle Projektstand regelmäßig dem Team und den Stakeholdern transparent gemacht. Dies verhindert Missverständnisse im Reporting und führt dazu, dass Risiken sowohl durch das Team als auch durch die Stakeholder bereits frühzeitig identifiziert werden und somit frühzeitig Maßnahmen zur Steuerung ergriffen werden können. Dies führt nicht nur dazu, dass Risiken früher erkannt werden, sondern ermöglicht es auch, ein Chancenmanagement zu etablieren. Die Entscheidung, welche Stakeholder aktiv am Review teilnehmen, wird im Zuge der Stakeholderanalyse getroffen. Impediment Backlog. Das Impediment Backlog zeigt alle Hindernisse, die vom Team identifiziert worden sind mit deren aktuellem Status. Es liefert einen Überblick, welche Risiken im Projektverlauf in der Praxis tatsächlich auftreten, und wie diesen begegnet werden kann. Diese Erkenntnisse können in andere Projekte einfließen und ermöglichen es, das Risikomanagement stetig weiter zu verbessern. Abbildung 1 Scrum Ereignisse User Stories. User Stories dienen zwei großen Zielen: Einerseits wird die Komplexität in beherrschbare Teile aufgeteilt, andererseits zeigen sie immer auch den Nutzen für einen Personenkreis auf: Damit möchte ich als folgende . Dadurch wird verhindert, dass Funktionen implementiert werden, deren Nutzen nicht nachgewiesen ist. Die Entwickler verstehen so, zu welchem Zweck die Funktion verwendet werden soll. Sie werden dazu befähigt, aktiv Verbesserungen einzubringen. Das Format der User Stories fördert die Diskussion zwischen allen Beteiligten auf einer nutzenbasierten Ebene. Es wird erleichtert, das Ziel der User Story nachzuvollziehen, um so gemeinsam zu einer bestmöglichen Lösung zu kommen. Durch die Verwendung von User Stories zur Anforderungserfassung wird aktiv das Risiko von Missverständnissen minimiert, so dass der Kunde das bekommt, was er benötigt, auch wenn er es nicht detailliert spezifiziert hat. Schätzungen und das Product Backlog. Alle Einträge im Product Backlog müssen geschätzt sein. Diese Forderung führt dazu, dass zu große oder komplexe Einträge identifiziert und weiter detailliert werden können. Auch wird während des Schätzens erkannt, ob alle Beteiligten das gleiche Verständnis der Aufgabe haben. User Stories, die zu unspezifisch oder zu groß sind, werden so frühzeitig erkannt und müssen vom Product Owner in Zusammenarbeit mit dem Team verkleinert werden. Hierdurch werden Risiken, die sich aus mangelnder Detaillierung oder fehlendem Verständnis ergeben, angegangen und entschärft. Darüber hinaus ist das Product Backlog nach Wertbeitrag sortiert, so dass immer als nächstes diejenigen Anforderungen umgesetzt werden, die dem Kunden den größten (Zusatz-) Nutzen bringen. Dies verringert das Risiko, dass gegen Projektende wesentliche Funktionen aufgrund fehlender Zeit oder Ressourcen nicht mehr umgesetzt werden können. Verantwortung. In Scrum übernimmt der Product Owner die Verantwortung für den wirtschaftlichen Erfolg des Produktes, der Scrum Master verantwortet die optimale Anwendung der Prozesse, und das Team ist für die technische Qualität verantwortlich. Durch diese Verantwortungsteilung und die damit verbundene Identifikation mit dem Produkt, wird erreicht, dass ein neues Risikobewusstsein entsteht. Das führt dazu, dass sich alle Beteiligten aktiv an der Risikoidentifikation, der Risikoanalyse und der Planung und Kontrolle von Maßnahmen beteiligen. Die Übertragung von Verantwortung auf das Team steigert seine Motivation. Dies wiederum fördert die Teambildung und mindert somit die damit verbundenen Risiken. Inspect and adapt. Durch laufendes Überprüfen und Anpassen der Zusammenarbeit, der Scrum Artefakte und des Fortschritts auf dem Weg zum gemeinsamen Ziel werden Abweichungen frühzeitig aufgedeckt. Ken Schwaber und Jeff Sutherland empfehlen, die Überprüfung regelmäßig vor Ort durchzuführen. In der Praxis sollte das gesamte Scrum Team den Fortschritt überprüfen, etwa im Daily Scrum. Werden Abweichungen erkannt und liegen diese außerhalb der tolerierbaren Grenzen sind geeignete Maßnahmen zu ergreifen, um den Arbeitsgegenstand oder den Prozess wieder zu korrigieren, da sonst die Gefahr besteht, dass das Produkt am Ende des Sprints ebenfalls außerhalb der tolerierbaren Grenzen liegt und damit das gemeinsam vereinbarte Sprintziel verfehlt wird. Potentially shipable increment. In Projekten mit klassischen Vorgehensmodellen liegt üblicherweise eine zu Anfang geringere Steigung der Wertschöpfungskurve vor, welche im weiteren Verlauf des Projektes zunimmt, vor. Durch das Credo „Maximize the amount of work not done“ wird bei agilen Projekten das Risiko, Arbeit zu bezahlen, die nicht benötigt wird, deutlich reduziert, auch deshalb wird typischerweise von Beginn an eine stärker steigende Wertschöpfungskurve erreicht. Vgl. Abbildung 2. Abbildung 2 Vergleich typischer Wertbeiträge in klassischen